1. Field of the Invention
The invention relates to design entry of electronic circuits. More particularly, the invention relates to a method for annotating timing into an HDL description of a circuit.
2. Description of the Background Art
As the electronics industry evolves, the typical operating speed of integrated circuits (ICs) changes frequently. Therefore, it is important for an IC designer to be able to rapidly determine the speed at which a signal will traverse a path through a proposed circuit in the IC. If the signal cannot traverse the path within the desired time period, the circuit may have to be modified or replaced. If the signal will predictably traverse the path in less than the available amount of time, some of the extra time may be used to perform other logical functions. Therefore, it is important to IC designers to be able to predict, with at least some degree of accuracy, the speed at which various portions of their circuits will operate. One field in which this requirement is particularly important is that of Field Programmable Gate Arrays (FPGAs), where a circuit may have different delays when implemented in different speed grades or in different FPGAs, and an FPGA may be selected for use in a system based primarily on the speed of the circuit as implemented in that particular FPGA.
One method for estimating circuit operating speed in an FPGA is a manual estimation technique that involves tracing each delay in the circuit manually and looking up delay values in tables provided by the FPGA manufacturer. One source for such information is "The Programmable Logic Data Book" (hereinafter referred to as "The Xilinx 1996 Data Book"), published in September, 1996 by Xilinx, Inc., and available from Xilinx, Inc., 2100 Logic Drive, San Jose, Calif. 95124. Suppose, for example, that an FPGA user wishes to predict the delay through a simple circuit such as a 2-input exclusive-OR (XOR2) gate, in an XC4003E FPGA device in the -2 speed grade. (Each Xilinx FPGA is assigned, after testing, a number preceded by a dash to indicate to which of several "speed grades" a particular packaged device is assigned. Each speed grade is guaranteed to meet a specific set of corresponding timing requirements.) The FPGA user must first be familiar enough with the architecture of the XC4003E device to realize that the XOR2 circuit can be implemented in a single function generator. The FPGA user can then predict the corresponding delay by consulting page 4-85 of the Xilinx 1996 Data Book, which is incorporated herein by reference, and a portion of which is reproduced in FIG. 1. Consulting this page, which is devoted to "XC4000E CLB Switching Characteristic Guidelines", the FPGA user looks under the heading "Combinatorial Delays" and identifies the symbol "TILO" as representing the delay through a single function generator. "TILO" for the -2 speed grade is 1.6 ns, therefore the delay for an XOR2-gate in an XC4003E-2 device is 1.6 ns. However, this estimated delay does not take into account such factors as net delay in reaching the inputs of the gate, nor a net delay on the gate output. In this case, the FPGA user might estimate a net delay of 0.5 ns, for a total delay through the XOR2-gate of 2.1 ns (1.6 ns block delay +0.5 ns net delay). For some circuits, these net delays can be larger than the delay through the function generator.
As a second example, consider a binary 8-bit counter such as the one shown in FIG. 2. This 8-bit counter comprises eight flip-flops (200-207). Each flip-flop corresponds to one bit of the counter, with flip-flop 200 generating bit Q0 (the least significant bit), flip-flop 201 generating bit Q1, and so forth up to flip-flop 207 generating bit Q7 (the most significant bit). Each flip-flop is reset by signal CLR. The data input D of flip-flop 200 is driven by bit Q0, inverted by inverter 210. Therefore, bit 0 toggles with every active edge on clock CK. The data inputs D of flip-flops 201-207 are driven by XOR2-gates 211-217, respectively. XOR2-gate 211 has as inputs Q1 (the related counter bit) and carry-in signal CIN1 (which could equally correctly have been labeled Q0 or as carry-out signal COUT0). Carry-in signal CIN1 and bit Q1 are also ANDed together in AND2-gate 221 to generate carry-out signal COUT1 (which is labeled CIN2, since it also forms the carry-in signal for the next bit). The other XOR2-gates 212-217 and AND2-gates 222-226 are similarly connected to the outputs Q2-Q7 of their corresponding flip-flops 202-207.
To manually estimate the delay through the counter the FPGA user must understand how the logic will be mapped into FPGA configurable logic blocks (CLBs) and function generators in the target FPGA device. When the counter shown in FIG. 2 is mapped into an XC4003E device, two bits of the counter will be placed in each CLB, as shown in FIG. 3. FIG. 3 indicates (by way of boxes 330, 332, 334, 336) the mapping of the logic in the counter into four CLBs. The maximum operating speed of this counter is determined by the settling time of the carry chain from least significant to most significant bit. The critical path (the path determining the maximum operating speed of the circuit) therefore comprises the path from clock CK, through flip-flop 200 to output Q0), then along the carry chain through AND2-gates 221, 222, 223, 224, 225, and 226, through XOR2-gate 217, and a setup time at flip-flop 207. Net delays from flip-flop output Q0 to the input of AND2-gate 221, and from each AND2-gate to the succeeding AND2-gate, must be added as well. The FPGA user can therefore calculate the estimated speed of the counter by summing: 1) clock-to-out for flip-flop 200; 2) six times the estimated average net delay from a flip-flop or AND2-gate output to an AND2-gate input; 3) five times the delay through an AND2-gate (one function generator delay each); 4) the delay through AND2-gate 226 and XOR2-gate 217 (one function generator delay for both); and 5) the setup time on input D of flip-flop 207. Consulting the data book information in FIG. 1, and estimating the average net delay based on previous experience with FPGAs, the estimated delay through the critical path for the counter of FIGS. 2 and 3 can be calculated: ##EQU1##
However, to provide a third example of manual delay estimation, XC4000E CLBs also offer special fast carry logic, and library macros (schematic or HDL circuit descriptions or symbols representing commonly used circuits, such as counters) that use this special logic are provided to XC4000E users. Speed estimation methods for counters and adders that use the fast carry logic are explained in Xilinx Application Note XAPP018 (Version 2.0), entitled "Estimating the Performance of XC4000E Adders and Counters", published Jul. 4, 1996 and available from Xilinx, Inc., 2100 Logic Drive, San Jose, Calif. 95124, which is incorporated herein by reference. Briefly, the propagation delay of an 8-bit counter using fast carry logic comprises the following delays: 1) the delay in getting onto the carry chain in the first CLB, corresponding to CLB 330; 2) two times the delay on the carry chain through a single CLB (two CLBs of two bits each, corresponding to CLBs 332 and 334); and 3) the delay in getting off the carry chain in the fourth CLB, corresponding to CLB 336. The delay can therefore be calculated using the formula: EQU Delay=TOPCY+(2*TBYP)+TSUM
Consulting the data book information in FIG. 1, the estimated delay of this counter in an XC4003E device with a -2 speed grade is found to be: EQU Delay=2.1 ns+(2*0.6 ns)+2.6 ns=5.9 ns.
Therefore, it is seen that the delay of even a simple circuit such as a counter may be heavily dependent on the particular implementation used in the macro, and the manual estimation method may be relatively involved.
A more automated method currently used for estimating the speed of an FPGA circuit involves mapping, placing, and routing the design, and writing out a netlist description of the completed design. (A "netlist" is a description of a circuit comprising a list of low-level circuit elements or gates and the connections (nets) between the outputs and inputs thereof. A netlist is typically stored as one or more computer files.) The next step is to run a software tool that inserts delays into the netlist corresponding to the delays that will be incurred by a signal traversing each element in the netlist. These delays are typically read from a file called a device speeds file. (A device speeds file may include delays for one or more different FPGAs or other programmable ICs, or may include delays for one or more elements in a standard cell library that may be used for designing custom ICs.) The device speeds file may be encrypted. A given FPGA device speeds file is typically specific to a particular FPGA device, and may include information for several different speed grades of the device. After inserting timing delays into the netlist, the software tool produces a report on the overall speed of the resulting design, or it can be directed to report the delay associated with a particular path through the design. One such software tool is the XDelay software from Xilinx, Inc. A step-by-step description of how to use the XDelay software to report path delays in a mapped, placed, and routed FPGA design is included in pages 15-39 through 15-43 of the "XACT Viewlogic Interface User Guide", published April, 1994, available from Xilinx, Inc., 2100 Logic Drive, San Jose, Calif. 95124, which are incorporated herein by reference. These methods typically produce relatively accurate reports of timing delays to be expected from the circuit when programmed into an FPGA.
One automated method for displaying timing for an FPGA circuit is described by Lawman and Wells in U.S. Pat. No. 5,673,198, "Concurrent Electronic Circuit Design and Implementation", which is incorporated herein by reference and title to which is held by the assignee hereof. However, this method requires software post-processing to map, place, and route the circuit before a timing estimate can be provided. This post-processing is often time-consuming.
FIG. 4 shows a schematic for an XOR2-gate that is used when designing circuits for Xilinx FPGAs using the Workview schematic entry environment from Viewlogic Systems, Inc. The XOR2-gate is an element in a library of macros provided by Xilinx or by Viewlogic Systems, Inc. to their customers. This XOR2-gate schematic is also a simulation model used to perform logic and timing simulations of the XOR2-gate and of higher-level schematics incorporating this gate. The schematic includes timing information for the gate. As shown in FIG. 4, the schematic comprises two buffer symbols 401, 402 and one symbol 403 representing the exclusive-OR function. Each of symbols 401, 402, 403 has two associated timing variables. For example, symbol 403 has the notation "TPLH=@ODLY1", which means that the Timing Period on the Low to High transition when passing through this logic is represented by a variable "ODLY1". Similarly, the notation "TPHL=@ODLY0" on symbol 403 means that the Timing Period on the High to Low transition is represented by a variable "ODLY0".
FIG. 5 shows the Workview XOR2 schematic symbol that corresponds to the XOR2 schematic of FIG. 4. (Timing attributes have been made visible using the Workview "Change Attributes Visible" command. Attributes other than timing variables are not shown in FIG. 5.) The timing variables from the schematic of FIG. 4 are also present in the schematic symbol of FIG. 5, and in FIG. 5 they are assigned default values. For example, the notation "@ODLY1=" means that the default delay for the low to high transition on symbol 403 is 1 timing unit, or 0.1 ns. (The basic time unit for Workview is 0.1 nanoseconds, or 100 picoseconds.) The notation "@IODLY0=0" in FIG. 5 means that the default delay for the high to low transition of symbol 402 is 0 ns. These attributes on the symbol are the Workview software's method of passing the timing information from the simulation model (shown in FIG. 4) to the Workview simulator. This timing information is nominal and does not reflect the performance of the circuit in a mapped, placed, and routed design. Therefore, it has no value for delay estimation purposes.
When the XOR2-gate of FIGS. 4 and 5 is converted to a Viewsim.TM. simulation netlist, the simulation netlist is written as appears in FIG. 6. (Viewsim is the Workview simulation software tool. Viewsim is a trademark of Viewlogic Systems, Inc.) The netlist description of FIG. 6 provides an example of how timing delays can be incorporated into a netlist. In this example, each symbol is represented by a single line of text. For example, symbol 403 is represented by line 600. FIG. 7 shows another type of netlist showing incorporation of the default delays. The netlist of FIG. 7 is in Xilinx. Netlist Format (XNF). In this netlist, symbol 403 is represented by lines 12 through 16 (labeled 700). To obtain a netlist having actual delays rather than the default values for TPHL and TPLH, the circuit must be mapped, placed, and routed, and the resulting netlist must be back-annotated with delays using the XDelay program.
An advantage to this automated method is that it is no more difficult for a user to obtain the delay through a large, complicated circuit than it is through a simple circuit such as an XOR2-gate, although it may take longer because of increased software execution time. A disadvantage of this method for estimating FPGA circuit delays is that the circuit must be implemented (mapped, placed, and routed) before the user can receive any information about the speed of the circuit. If design changes are made as a result of the timing information, the circuit must be reimplemented to assess the results of the changes. Further, in order to implement the circuit, the circuit must be transformed into a complete FPGA design, i.e., input/output pads must be added, and each circuit output must either drive some destination circuitry or be marked so the software will retain what appears to be unused logic. This process can therefore be time-consuming. Some FPGA users prefer to make one or more iterations of the design process based on a manual estimation of the delay through the circuit, before proceeding to the accurate estimations produced by the above method.
Another common method of describing a circuit, other than with a schematic, is by textual description in a Hardware Description Language (HDL). There are several standard HDL languages; two commonly used HDL languages are Verilog and VHDL. In addition, there are a number of distinct coding styles for entering a circuit description in an HDL, including behavioral, dataflow, and structural descriptions. These languages and coding styles are well known in the HDL art and are not discussed in detail herein. Exemplary circuit descriptions herein are written in the Verilog language.
A common technique used in HDL circuit descriptions is the instantiation (essentially the inclusion of a copy by reference) of a previously implemented macro. The following Verilog code fragment shows the instantiation of an exemplary macro:
CPU.sub.-- core U1 (Addr, Data, CS, CE, RD.sub.-- WR.sub.-- n, INT, Clk); PA1 DMA.sub.-- core U2 (Addr, Data, CS2!, CE2!, RD.sub.-- WR.sub.-- n, INT1!, Clk);
In this example the macro is named `CPU.sub.-- core`. This particular instance (instantiation) has a unique instance reference name U1. The list of signal names (in parentheses) is called a port list. In this example, the port list shows that the CPU.sub.-- core macro has connections to an address bus (Addr), a databus (Data), and numerous control signals (signal lines or buses) such as CS (Chip Select), CE (Chip Enable), and so forth. The port list is used to connect the macro to other portions of the design, which often includes other such instantiations. For example, in addition to instance U1 above, a design may contain an instantiated DMA core such as the following:
In this example, the two macros are connected by way of the commonly labeled signals through the macro ports in the port list. For example, the CS2! entry in the DMA core's port list indicates that the DMA is connected to bit 2 of the CPU core's CS bus, while the two macros share clock signal "Clk".
In Verilog, the port names in the instantiation port list may or may not be the same names as those used for the same ports within the library macro. However, instantiation port names are assigned to the macro ports based on the order in which they appear in the port list (as in the examples above), or alternatively can be connected in the instantiation port list using notation such as ".macro.sub.-- internal.sub.-- port.sub.-- name(instantiation.sub.-- name)".
An HDL description (which may optionally contain one or more macro instantiations) typically describes in text form the desired structure or behavior of a circuit, and the HDL description is then compiled or synthesized by HDL synthesis software to produce a netlist. This netlist may be substantially similar to a netlist produced from a schematic. The delay through an HDL circuit can therefore be estimated using the same methods used for schematic circuits, i.e., by manually estimating the delay through each element and adding the delays, or by mapping, placing, and routing the circuit and running timing estimation software such as the XDelay software from Xilinx, Inc. The manual estimation method may be more difficult with an HDL description than with a schematic description, because it is not always apparent from the HDL description (particularly a behavioral description) what circuit elements will be used to implement the circuit.
It is desirable to have a way of estimating the delay through an FPGA circuit from either a schematic description or an HDL circuit description, without consulting a data book, without manually adding together many small delays, and without mapping, placing and routing the circuit.